fix: Signal a link that resolves into a watched directory, and say which deployments watching does not follow - #484

Summary

Follow-up to #449 for two findings raised on the Python port of the same watcher (launchdarkly/python-server-sdk#525), both of which apply here.

• A configured link that cannot be resolved keeps the once-per-second retry running. When a retry resolved such a link to a target in a directory that was already watched, for example because another configured file is in it, it added no watch and so ran no callback. Content that appeared while the link could not be resolved was then not read until some later change. refresh_links now reports a change whenever a link leads to a target it did not lead to before, so the retry runs the callback once.
• The watcher comment said that a link that comes to point elsewhere is followed. That holds when the old target's directory is deleted, as a ConfigMap update does, but not for a link further along the chain that is pointed elsewhere while its old target stays, a configured directory that is itself a link and is pointed elsewhere, or a configured directory that is renamed and replaced. The comment now names those cases and points such deployments, like a current link to a release directory, to polling, which is the default. The override source's change_detection documentation says the same in feat: Add the file-based override source #453.

Tests

A new watcher spec configures a link that leads through a directory that does not exist yet to a directory that another configured file keeps watched, then creates the missing directory as a link. It fails without the change and passes with it. The watcher specs pass (24 examples), the full suite passes apart from spec/launchdarkly-server-sdk_spec.rb:5, which fails the same way on feat/overrides on this box because Bundler cannot write its lock file, and RuboCop reports no offenses.

SDK-3249

_{Opened from termag}